Apparatus and method for processing data relating to events on a network

ABSTRACT

A network management apparatus and method processes network management data received during the monitoring of a network and generates events for presentation in an event list to a user when certain event conditions are detected. Network management data received in relation to an event condition is processed to determine whether it represents a recurring event condition. A recurring event condition is determined if a predetermined number of equivalent events have been generated, and appear in the event list, in an immediately preceding time period. In the described embodiment, if a recurring event condition occurs, a recurring event is generated, and subsequent occurrences of the event condition are not included in the event list presented to the user.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The following patent applications filed concurrently herewith arerelated to the present application and are incorporated herein byreference:

[0002] U.S. Patent application (Attorney Reference 3COM3584) entitled“Processing Network Events to Reduce the Number of Events to beDisplayed”;

[0003] U.S. Patent application (Attorney Reference MBHB01-494) entitled“Network Management Apparatus and Method for Determining NetworkEvents”, and

[0004] U.S. Patent Application (Attorney Reference MBHB01-493) entitled“Network Management Apparatus and Method for Processing Eventsassociated with Device Reboot”.

BACKGROUND OF THE INVENTION

[0005] 1. Field of the Invention

[0006] The present invention relates generally to an apparatus andmethod for the management of a network, and more particularly to anetwork management apparatus and method which monitors a network, andgenerates Events when certain types of conditions are detected.

[0007] 2. Description of the Related Art

[0008] The following description is concerned with a data communicationsnetwork, and in particular a local area network (LAN). It will beappreciated, however, that the invention but has more widespreadapplicability to other managed communications systems including widearea networks (WANs) or wireless communications systems. Networkstypically comprise a plurality of computers, peripherals and otherelectronic devices capable of communicating with each other by sendingand receiving data packets in accordance with a predefined networkprotocol. Each computer or other device on the network is connected by aport to the network media, which in the case of a LAN network may becoaxial cable, twisted pair cable or fibre optic cable. A network isgenerally configured with core devices having a plurality of ports,which can be used to interconnect a plurality of media links on thenetwork. Such devices include hubs, routers and switches which pass datapackets received at one port to one or more of its other ports,depending upon the type of device. Such core devices can be managed orunmanaged.

[0009] A managed device is capable of monitoring data packets passingthrough its ports and obtaining data relevant for network management.Managed devices additionally have the capability of communicating thisdata using a management protocol such as the SNMP (Simple NetworkManagement Protocol), as described in more detail below. The skilledperson will appreciate that the invention is not limited to use withSNMP, but can be applied to managed networks using other networkmanagement protocols.

[0010] SNMP defines agents, managers and MIBs (where MIB is ManagementInformation Base), as well as various predefined messages and commandsfor data communication. An agent is present in each managed networkdevice and stores management data and responds to requests from themanager. A manager is present within the network management station of anetwork and automatically interrogates the agents of managed devices onthe network using various SNMP commands, to obtain information suitablefor use by the network administrator, whose function is described below.A MIB is a managed “object” database which stores management dataobtained by managed devices, and is accessible to agents for networkmanagement applications.

[0011] It is becoming increasingly common for an individual, called the“network administrator”, to be responsible for network management, andhis or her computer system or workstation is typically designated thenetwork management station. The network management station incorporatesthe manager, as defined in the SNMP protocol, i.e. the necessaryhardware, and network management software applications to retrieve datafrom MIBs by sending standard SNMP requests to the agents of manageddevices on the network.

[0012] A part of the network administrator's function is to identify andresolve problems occurring on the network, such as device or linkmalfunction or failure. In order to provide the network administratorwith the necessary information to identify such problems, the networkmanagement application monitors the devices on the network. An exampleof such monitoring is described in co pending UK Patent Application No9917993.9 entitled “Management System and Method for Monitoring Stressin a Network” in the name of the present applicant. In the system andmethod described in UK Patent Application No 9917993.9 the SNMP managerin the network management station requests the agents of managed networkdevices on the network to retrieve selected MIB data indicative ofdevice and link operation, and performs tests for device activity andservice availability. Such MIB data may relate to characteristics suchas traffic activity or errors occurring at a particular port in therelevant network device. Tests may include sending ICMP Ping requests toeach device on the network, or sending selected requests for servicessuch as SMTP, NFS and DNS to servers, and monitoring the time taken toreceive a response. The monitored parameters or characteristics arereferred to herein as “stress metrics”.

[0013] The network management application compares, for each stressmetric, the retrieved data or test results against a correspondingthreshold level for the stress metric. The threshold level is the levelabove which performance is considered to be unacceptable.

[0014] Each time a threshold is exceeded, the application generates andlogs an “event” in memory. An “event log” stores each event, andincludes information such as the date and time of the event, theidentity of the device affected and the nature of the event. The eventlist thus provides a history of events which have occurred on thenetwork, and the network administrator can review the event list toidentify problems on the network.

[0015] In addition to events resulting from the monitoring of stressmetrics, events may also be generated by the network managementapplication when other types of condition are detected. For example, anetwork management application may receive an asynchronous Trap, forexample an SNMP Trap from a managed network device. An SNMP Trap isautomatically sent by an SNMP agent to the SNMP manager when certainconditions are detected by the agent in the managed device. Examples ofconditions which cause SNMP Traps to be sent include “link up” and “linkdown”. When an SNMP Trap is received by the network management station,the management application may log an event.

[0016] An example of a known network management software applicationcapable of determining monitoring the stress of a network is the 3Com®Network Supervisor available from 3Com Corporation of Santa Clara,Calif. U.S.A. This application, and similar applications, uses SNMPcommands to retrieve relevant management data from managed networkdevices, and processes the data as described below.

[0017] The event log is the main source of information used by thenetwork administrator in order to identify problems on the network.Accordingly, it will be appreciated that the manner of presentation ofevents to the network administrator in the event list is important. Thenetwork administrator needs to be able to identify problems easily andwithout having to review a long list of insignificant events.

[0018] Some network management applications present each event in theevent log with a “severity” indication. The severity indication isdependent on the nature of the event and other factors such as thedegree to which a stress metric threshold is exceeded. For example, ifthe threshold for a stress metric is exceeded by a small amount, theseverity indication may be “High”, if the amount by which the thresholdis exceeded is more significant the severity indication may be “Warning”and if the threshold is exceeded by even larger amounts the indicationmay be “Critical”.

[0019] Thus, the severity indication enables the network administratorto determine the events which need the most urgent attention. However,this does not address the problem of large numbers of events appearingin the event log.

[0020] Another problem encountered by the network administrator inreviewing events in the event log is associated with events generated asa result of an intermittent or “recurring” problem on the network. Forexample, a problem, such as congestion on a particular link, may occurat certain times of heavy network traffic throughout the day. Each timethe link becomes congested, having previously been operating normally,an event is generated. This leads to the event list displaying a largenumber of identical/equivalent events showing congestion on the link,interspersed between other unconnected events. This can make itdifficult for the network administrator to identify and determine thatthe events indicating congestion on the link are indicative of a singlerecurring network problem (i.e. a recurring problem on a specific,single network device or link). In addition, the inclusion of a separateevent on each occurrence of a recurring problem may obscure otherunrelated, yet more significant events.

[0021] The present invention seeks to address these problems.

[0022] In the aforementioned co-pending U.S. Patent Application entitled“Processing Network Events to Reduce the Number of Events to beDisplayed” filed simultaneously herewith, there is described a methodand apparatus in which events generated by a network management systemare passed through one or more “event processors” to correlate eventsprior to presentation in an event list. Each processor is adapted tocorrelate certain types of events which may be generated as a result ofcertain conditions or problems on the network. This correlation ensuresthat the number of events presented in the event list is reduced, byavoiding presenting certain types of event which, generally speaking,are less informative about network conditions and problems to the user.

SUMMARY OF THE INVENTION

[0023] The present invention provides a method which may be implementedby one such event processor, and an apparatus which may comprise such anevent processor.

[0024] Generally, the present invention provides a network managementapparatus and method which identifies and correlates recurring, that isrepeatedly occurring, events. In accordance with a first aspect, thepresent invention provides a method for processing events generated by anetwork management system during the monitoring of a network forpresentation in an event list to the user, the method comprisingreceiving an event, and determining if a predetermined number ofequivalent events have been generated in a preceding time period.

[0025] If it is determined that a predetermined number of equivalentevents have been generated in an immediately preceding time period, theevent is considered to be a recurring event.

[0026] In a preferred embodiment, if a recurring event is determined,the method generates an event marked as recurring for presentation inthe event list. In addition, the method prevents subsequent equivalentevents from being presented in the event list to the user. This avoidsthe presentation of further occurrences of the recurring event to theuser.

[0027] In one embodiment, if a recurring event is determined followingthe receiving of the event, the method includes in the event data of theevent marked recurring a second time (e.g. a “time stamp”) correspondingto the time of the received event to represent the time of the last ormost recent occurrence of the event. If a subsequent occurrence of theevent is received, this time is updated to the time of the subsequentevent.

[0028] In accordance with a second aspect, the present inventionprovides a computer readable medium including a computer program forcarrying out the method in accordance with the first aspect of thepresent invention.

[0029] In accordance with a third aspect, the present invention providesa network management apparatus for generating events during themonitoring of a network, and for presenting the generated events in anevent list to the user, the apparatus comprising a processor forreceiving an event, and for determining if a predetermined number ofequivalent events have been generated in a preceding time period.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Embodiments of the present invention will now be described, byway of example, with reference to the accompanying drawings, in which:

[0031]FIG. 1 is a block diagram of a typical network having a networkmanagement station which may be employed in accordance with the presentinvention, and

[0032]FIG. 2 is a flow diagram illustrating the steps of a computerprogram for carrying out a method in accordance with a preferredembodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033]FIG. 1 shows a typical network 1 incorporating a networkmanagement system according to a preferred embodiment of the presentinvention. The network 1 includes a network management station 3A whichincorporates the necessary hardware and software for network management.In particular, the network management station 3A includes a processor, amemory and a disk drive as well as user interfaces such as a keyboardand mouse, and a visual display unit. Network management applicationsoftware in accordance with the present invention is loaded into thememory of management station 3A for processing data as described indetail below. The network management station 3A is connected by networkmedia links 5 to a plurality of managed network devices including coredevices such as network switch 7, hubs 11 and 12, and a router (notshown) which may be managed or unmanaged, and end stations includingpersonal computers (PCs) 3 and workstations. The network may alsoinclude unmanaged devices, for example peripheral devices such asprinters.

[0034] The network management station 3A is capable of communicatingwith the managed network devices such as network switch 7 and hubs 11and 12 by means of a network management protocol, in the presentembodiment the SNMP protocol, in order to obtain network managementdata. Each managed device includes an SNMP agent which monitorsoperational characteristics and stores the monitored data as MIB data inmemory on the device, as is well known in the art, including datarelating to inter alia data traffic passing through the device.

[0035] In accordance with the preferred embodiment of the presentinvention, the network management station 3A monitors a plurality ofstress metrics. The stress levels or values for the metrics are obtainedby periodically requesting relevant MIB data from hubs 11 and 12 andswitch 7, and by periodically polling all network devices using Ping orservice requests and monitoring response times.

[0036] The network management station 3A compares each monitored stresslevel against a corresponding predetermined threshold level for thestress metric. Each time a threshold is exceeded, the network managementstation 3A stores details about the monitored stress level in an eventlog in memory. In particular, the event data stored in the event logincludes the time of the event (e.g. by way of a “time stamp”), theidentity of the device concerned, the identity of the stress metric andthe severity of the event.

[0037] The memory typically stores the event data in the form of adatabase or similar data file, which stores event data in different timeintervals separately. Thus, the database provides a history of eventsthat have occurred on the network for different time periods. It shouldbe noted that monitored stress levels which do not exceed the thresholdare not stored in the event log, in accordance with the preferredembodiment, and the received data about these monitored levels isdiscarded or overwritten by subsequent monitored stress levels. It willbe appreciated that in other embodiments all monitored stress levels forsome or all time intervals may be stored in the database.

[0038] A typical list of events recorded in an event log is shown inTable 1 below. Each event listed in the Table represents an event whichhas been generated as described above. TABLE 1 Time Device EventCondition Severity 2.00 switch 7, port 1 link errors Warning 2.03 switch7, port 1 link errors Warning 2.04 switch 7, port 1 link errors Warning2.06 switch 7, port 1 link errors Warning 2.08 switch 7, port 1 linkerrors Warning 2.10 hub 11, port 2 link congestion High 2.10 switch 7,port 1 link errors Warning 2.14 switch 7, port 1 link errors Warning2.15 hub 11, port 2 device down High 2.16 switch 7, port 1 link errorsWarning 2.20 switch 7, port 1 link errors Warning

[0039] In the example illustrated in Table 1, the event log repeatedlylogs an error on the link to port 1 of switch 7. Other types of errorwhich may recur repeatedly over time include: repeated congestion on aparticular link; slow provision of service by a network server device,and repeated failure by a network device to respond to a managementrequest (e.g. IP Ping request). The skilled person will appreciate thatother types of errors may also occur intermittently with time and leadto repeated event generation.

[0040] The recurrence of the event in Table 1, indicating errors on thelink connected to port 1 of switch 7, represents an intermittent,recurring problem with the link. In particular, in this example, thelink is monitored every 30 seconds, and so it can be deduced from theevent log that the link was operating normally, for example, between2.00:30 and 2.02:30 and at 2.05. The event list shown in Table 3 is thuscluttered with events due to this recurring network problem whichobscure more significant errors such as the problems with hub 11 at 2.10and 2.15.

[0041] The present invention avoids including so many events, which arerepeatedly generated due to an intermittent problem on the network, forpresentation in the event list to the user.

[0042]FIG. 2 shows a method in accordance with an embodiment of thepresent invention. The method is implemented in a computer programforming part of network management software application. It will beappreciated that in other embodiments the method may be implemented inother forms such as in hardware.

[0043] In particular, the method of the preferred embodiment isperformed in a network management station in accordance with the presentinvention. The network management station 3A comprises a processor, adisk drive, memory, and user interfaces including a display screen,keyboard, mouse, and a printer. The computer program described above istypically provided on a computer readable medium, such as a disk, and isloaded onto the network management station using the disk drive and theprocessor runs the program. Alternatively, the computer program may becarried on a computer system having the website of, for example, thesupplier of network devices, which permits downloading of the programover the Internet on a carrier wave to the network management station3A.

[0044] The program illustrated in FIG. 2 relates to a particularmonitored characteristic for a particular network device. Networkmanagement data including the value (level) of the monitoredcharacteristic (stress metric) is retrieved periodically by the networkmanagement software application. For example, the data may be retrievedat regular time intervals of 30 seconds. It will be appreciated thatother time intervals are possible.

[0045] Thus, at step 110, the program waits for a predefined time periodcorresponding to the aforementioned time interval. In the preferredembodiment, the predefined time period is 30 seconds.

[0046] At step 120, the program retrieves the value of the monitoredcharacteristic of the relevant network device, and at step 130 considerswhether the value is above a predefined threshold for the monitoredcharacteristic.

[0047] It will be appreciated that steps 110 to 130 may be implementedby a conventional network management software application.

[0048] If step 130 determines that the value received at step 120 is notabove the predefined threshold, the program returns to step 110 andwaits for 30 seconds before retrieving the next value for the monitoredcharacteristic.

[0049] If step 130 determines that the value received at step 120 isabove the predefined threshold, an event condition has occurred and theprogram passes data relating to the event condition to step 140 forprocessing.

[0050] At step 140, the program considers whether the monitoredcharacteristic for the relevant network device is in a recurring state.In particular, the program considers whether a corresponding existingevent appears in the event log which is marked as “recurring”. Themanner in which events are marked as recurring is described below inrelation to steps 150 and 160.

[0051] If step 140 determines that the monitored characteristic is in arecurring state, the program proceeds to step 180. Otherwise, that is,if step 140 determines that the monitored characteristic is not in arecurring state, the program proceeds to step 150

[0052] At step 150, the program considers whether there are already mcorresponding existing events in the event log, the oldest of whichoccurred in the previous time period of t1 seconds (where m and t1 areinteger values greater than 0). In the preferred embodiment, the valueof m=4 and the value of t1=7200 (time period=2 hours). It will beappreciated that other values for m and t1 are possible, andcontemplated. However, m is typically in the range of 3 to 7 and t1 istypically several hours.

[0053] In particular, at step 150, the program scans the event log forevents in which the event data indicates a corresponding event with atime stamp in the immediately preceding time interval t1. It will beappreciated that the instead of scanning data in the event log, thenetwork management application could maintain internal “state”information relating to events in the event log, typically stored asvariables or lists for use when processing subsequent events.

[0054] If step 150 determines that there are already m correspondingevents in the event log, the oldest of which occurred in the precedingt1 seconds, the program proceeds to step 160. Otherwise, the programproceeds to step 170 by logging the event in the event log. In step 170,the event is logged as a normal event.

[0055] At step 160, since the event condition has now occurred more thanm times in the last t1 seconds, the program logs a recurring event. Inparticular, in the preferred embodiment, the program generates a newevent for the monitored value received at step 120 which is marked as“recurring” and logs it in the event log. In addition, an internal stateof the monitored characteristic may be marked “recurring”, e.g. bysetting a variable to indicate a recurring state. As the skilled personwill appreciate, an event may be marked as in a recurring state in anumber of different ways, but in the preferred embodiment, the severityindication in the event data is given accorded a special state or code,which appears in the event list as “recurring”.

[0056] In addition, the event data for recurring events may include anadditional time stamp to indicate the most recent occurrence of theevent, as will be appreciated from the following description.

[0057] Following step 160, the program returns to step 110.

[0058] Returning to step 140, if step 140 determines that the monitoredvalue is in a recurring state, then, at step 180, the program scans theevent log and considers whether the event condition has occurred morethan n times in the previous time period t2 (where n and t2 are integervalues greater than 0). In the preferred embodiment, n=1 and t2=14400seconds (time period=4 hours). The skilled person will appreciate thatother values for n and t2 are possible, and, like m and t1 should bechosen according to the operating characteristics of the networkmanagement software application and depending upon the type of monitoredcharacteristic involved. Again, it will be appreciated that instead ofscanning the event log, the network management application couldmaintain internal “state” information relating to events in the eventlog, typically stored as variables or lists for use when processingsubsequent events.

[0059] If step 180 determines that the event condition has occurred morethan n times in the preceding time period t2, then it is considered thatthe event remains a recurring event and the program proceeds to step200. Alternatively, if step 180 determines that the event condition hasnot occurred more than n times in the preceding time period t2, then theevent is no longer considered to be a recurring event and the programproceeds to step 190.

[0060] At step 200, the program may not generate an event in response tothe event condition indicated by the monitored value retrieved by step120, but instead ignores the event condition, for presentation purposes.However, the event data is logged in memory in the preferred embodiment,so that the data can be looked at during subsequent scanning steps 150or 180. In this case the data is hidden from the user, and not presentedin the event list. In the preferred embodiment, in addition to ignoringthe event condition, the program updates the additional time stamp inthe recurring event with the current time, so that the additional timestamp indicates the most recent time that the event condition occurred.

[0061] Following step 200, the program returns to step 110.

[0062] At step 190, the program logs an event in the event log. A normalevent is logged for the monitored value received at step 120, that is,it is not marked in the recurring state. Thus, in the preferredembodiment, the severity of the event is recorded in the conventionalmanner depending upon the value and the threshold. In addition, if thestate of the monitored characteristic is maintained internally at step190 it is changed from recurring to non-recurring.

[0063] Following step 190, the program returns to step 110.

[0064] The following Table 2 illustrates the events that will appear inthe event list when the program illustrated in FIG. 2 is applied to thedata relating to the events received and illustrated in Table 1 above.TABLE 2 Time Device Event Condition Severity 2.00 switch 7, port 1 linkerrors Warning 2.03 switch 7, port 1 link errors Warning 2.04 switch 7,port 1 link errors Warning 2.06 switch 7, port 1 link errors Warning2.08 switch 7, port 1 link errors Recurring 2.10 hub 11, port 2 linkcongestion High 2.15 hub 11, port 2 device down High

[0065] Thus, it can be seen that the number of events relating to linkerrors on the link to port 1 of Switch 7 is reduced, due to the fifthoccurrence of the event condition at 2.08 being marked as a recurringevent. In addition, since subsequent occurrences do not appear in theevent list, the unrelated events at 2.10 and 2.15 are no longer obscuredby individually logged instances of the recurring event condition. Thenetwork administrator is therefore provided with a better indication ofthe state of the network.

[0066] As the skilled person will appreciate, various modifications andchanges may be made to the described embodiments.

[0067] For example, steps 180 and 190 of the preferred embodiment may beomitted. Thus, if step 140 determines that the monitored characteristicis in a recurring state, the program will simply proceed to step 200 andignore the event condition.

[0068] As an alternative to step 160, the program may instead ignore theevent condition resulting from the value received at step 120, andinstead update the most recent of the m existing events by marking it asrecurring, or changing its severity indication to recurring. Inaddition, a time stamp may be added to the data from that event,indicating the current time and thus the time of the most recentoccurrence of the event condition.

[0069] The present invention is not limited to use in relation tomonitored characteristics in which an event condition arises if amonitored value exceeds a predefined threshold. Rather steps 140 to 200of the preferred embodiment can be adapted for use with other types ofmonitored characteristics.

[0070] It is intended to include all such variations, modifications andequivalents which fall within the spirit and scope of the presentinvention as defined in the accompanying claims.

1. A method for processing network management data in a networkmanagement system which generates events, for presentation in an eventlist to a user, when event conditions are detected during the monitoringof a network, the method comprising receiving network management datarelating to an event condition, and determining whether a predeterminednumber of equivalent events have been generated in a preceding timeperiod.
 2. A method as claimed in claim 1, wherein, if it is determinedthat the predetermined number of equivalent events have been generatedin the preceding time period, the method further comprises generating arecurring event.
 3. A method as claimed in claim 2, further comprisingreceiving data relating to a subsequent occurrence of the eventcondition, and preventing a subsequent event from being presented in theevent list to the user.
 4. A method as claimed in claim 3, furthercomprising adding a time stamp to the event data of the recurring event,the time stamp indicating the time of the subsequent occurrence of theevent condition.
 5. A method as claimed in claim 1, wherein thepreceding time period is an immediately preceding predetermined timeperiod.
 6. A method as claimed in claim 5, wherein data relating to anevent is recorded in an event storage and includes the time of theevent, the step of determining whether a predetermined number ofequivalent events have been generated in a preceding time periodcomprising: determining the number of equivalent events in the eventstorage having a time within the predetermined time period, andcomparing the determined number with the predetermined number.
 7. Amethod as claimed in claim 1, wherein, if it is determined that apredetermined number of equivalent events have been generated in thepreceding time period, the method places one of the equivalent events ina recurring state and prevents the received data relating to the eventcondition from being presented in the event list to the user.
 8. Amethod for processing network management data in a network managementsystem which generates events, for presentation in an event list to auser, when event conditions are detected during the monitoring of anetwork, the method comprising receiving network management datarelating to an event condition; determining whether the monitoredcharacteristic for the event condition is in a recurring state, andprocessing the data according to whether the monitored characteristicfor the event condition is in a recurring state.
 9. A method as claimedin claim 8, wherein the step of determining whether the monitoredcharacteristic for the event condition is in a recurring state comprisesconsidering whether a recurring event in relation to the event conditionis present in the event list, and if so, determining that the monitoredcharacteristic for the event condition is in a recurring state.
 10. Amethod as claimed in claim 8, wherein, if it is determined that themonitored characteristic for the event condition is in a recurringstate, the method farther comprises determining whether the eventcondition has occurred more than a first predetermined number of timesin a first preceding time period.
 11. A method as claimed in claim 10,wherein, if it is determined that the event condition has occurred morethan the first predetermined number of times in the first preceding timeperiod, the method further comprises preventing the received datarelating to the event condition from being presented in the event listto the user.
 12. A method as claimed in claim 10, further comprisingadding to event data of the event in the recurring state the time of thereceived data relating to the event condition.
 13. A method as claimedin claim 10, wherein, if it is determined that the event condition hasnot occurred more than the first predetermined number of times in thefirst immediately preceding time period, the method further comprisesgenerating an event for presentation in the event list to the user. 14.A method as claimed in claim 13, wherein the generated event is not arecurring event.
 15. A method as claimed in claim 8, wherein if it isdetermined that the monitored characteristic for the event condition isnot in a recurring state, the method further comprises determiningwhether a second predetermined number of equivalent events have beengenerated in a second preceding time period.
 16. A method as claimed inclaim 15, wherein, if it is determined that the second predeterminednumber of equivalent events have been generated in the second precedingtime period, the method further comprises generating a recurring event.17. A method as claimed in claim 16, wherein, after the step ofgenerating a recurring event, the method further comprises receivingdata relating to a subsequent occurrence of the event condition, andpreventing a subsequent event from being presented in the event list tothe user.
 18. A method as claimed in claim 17, further comprising, afterthe step of receiving data relating to a subsequent occurrence of theevent condition, adding a time stamp to the event data of the recurringevent, the time stamp indicating the time of the subsequent occurrenceof the event condition.
 19. A method as claimed in claim 15, wherein, ifit is determined that the second predetermined number of equivalentevents have not been generated in the second preceding time period, themethod further comprises generating an event for presentation in theevent list to the user.
 20. A method as claimed in claim 10, wherein thefirst and/or second preceding time period is an immediately precedingpredetermined time period.
 21. A computer readable medium including acomputer program for carrying out the method as defined in claim
 1. 22.A computer program for processing network management data in a networkmanagement system which generates events, for presentation in an eventlist to a user, when event conditions are detected during the monitoringof a network, the program comprising a program step receiving networkmanagement data relating to an event condition for determining whether apredetermined number of equivalent events have been generated in apreceding time period.
 23. A network management apparatus for monitoringa network and for processing network management data and generatingevents, for presentation in an event list to a user, when eventconditions are detected, the apparatus comprising a processor forreceiving network management data relating to an event condition, andfor determining whether a predetermined number of equivalent events havebeen generated in a preceding time period
 24. A network managementapparatus for monitoring a network and for processing network managementdata and generating events, for presentation in an event list to a user,when event conditions are detected, the apparatus comprising a processorfor receiving network management data relating to an event condition andfor determining whether the monitored characteristic for the eventcondition is in a recurring state, and processing the data according towhether the monitored characteristic for the event condition is in arecurring state.